# Information security incident management ## Part 2: Guidelines to plan and prepare for incident response 1. How to respond to information security events and incidents 2. Determine when events become incidents 3. Manage an incident to its conclusion, and ensure there's responsibility allocated for this. Ideally this is a named individual 4. Who's responsible for information security [[vulnerability|vulnerabilities]]? Remember they go wider than just the IT team 5. What requirements are there for reporting? 6. What information must be stored during the whole incident management process, and how is that done? Consider that an incident might be one that brings your productivity software offline 7. Rules and circumstances when information should be shared, both internally and externally 8. Identify lessons that can be learned, and any improvements that must be made to planning and security. Again, this may be wider than just IT. 9. Implement those improvements ## Clause 4: Information security [[incident]] management policy NB: this clause is tightly coupled to [[ISO 27035-1]], clause 5.2 a ### 4.1 General - the incident management policy should support decision makers by clearly documenting both principles and intentions - information security strategy must encompass incident managment policy - the policy should outline the processes, responsible persons, authority and reporting lines for when an incident occurs - ugh, stop saying 'event', it means something else in [[NIST SP 800-61]] - before writing the policy, the organisation needs a handle on the following with regards to incident management: - the principles, objectives, and purpose - the scope, in terms of the parts of the organisation it touches, the information [[assets|assets]] it covers, and the types of [[incident]] and [[vulnerability]] it is responsible for controlling and resolving - internal and external parties - specific roles that are involved - benefits to the entire organisation, as well as neighbouring business units - an understanding of its legal and regulatory environment - what dependencies it has, including abstract dependencies such as alignment to risk management - the skills and competencies required ### 4.2 Interested parties - everyone with a stake in information security management should be involved in creating the policy - everyone! and that might include colleagues in facilities management, human resources, legal, PR... - top management should support the policy, and management at all levels should commit to to it and share it with their line reports - trust again! - everyone should be able to recognise an incident, know it for what it is, and know what steps they should take - and therefore the policy should be made available to everyone, both permanent and temporary staff ### 4.3 Information security incident management policy content - policy documents are intentionally high level without much detail on implementation - Like an API...? I wonder - check the document for full content - too much to write here: https://bsol.bsigroup.com/PdfViewer/Viewer?pid=000000000030400006 ## Clause 5: Updating of information security policies ## Annex B: Example forms for information security events, incidents, and [[vulnerability]] reports - a lot of handy examples here for reporting - I should find out if anyone's written these up somewhere ## Annex C: Example approaches to the categorisation, evaluation and prioritisation of information security events and incidents